The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
Queries issued to a database typically target one or more one or more database objects, such as relational tables. Many times, accessing data organized in a relational table involves scanning the relational table or at least a portion thereof. A common SQL query is one that requires a filter on a database table, such as the following:                select EMPLOYEE from T_EMPLOYEES where HIRE_YEAR=‘2012’        
In this example, that database table T_EMPLOYEES is searched for all the employees who were hired in 2012. This search (or “scan”) is done by software running on one or more microprocessors that execute a series of instructions to search through the table for the specified value, which is ‘2012’ in this example. The first step is typically the performance bottleneck when running analysis applications on a large database, since this step has to run on the entire table, which may be several terabytes large. Subsequent steps will work on the filtered subset of the first scan step that meets the criteria set in the scan (employees hired in 2012 in the above example). Therefore, the number of rows that a machine can filter per unit of time is an important performance metric for the machine. This metric is referred to as the “scan rate.”
Approaches for processing queries, such as queries that involve scanning a table, have relied on software techniques, where the software is executed (or “runs”) on a general purpose microprocessor.